GH#837: fix network activation reliability in multisite setup wizard#852
Conversation
superdav42
added
the
origin:worker
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 39 minutes and 6 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…ation The _install_network_activate() step in Multisite_Network_Installer relied on activate_plugin() to network-activate the plugin. That function checks is_multisite() internally and falls back to single-site activation when it returns false. The MULTISITE constant is written to wp-config.php only in the immediately-preceding step (_install_update_wp_config); if OPcache or another PHP bytecode cache serves a stale wp-config.php in the next AJAX request, is_multisite() returns false and the plugin ends up activated as a single-site plugin instead of network-wide — matching the 'sometimes fails' behaviour reported in GH#837. The fix writes directly to the sitemeta table (as the original code comment already intended), bypassing activate_plugin() entirely. This guarantees network activation regardless of whether the current PHP process has loaded the new multisite constants. Also fixes the early-return guard which used the full absolute path (WP_ULTIMO_PLUGIN_FILE) instead of the plugin basename (WP_ULTIMO_PLUGIN_BASENAME), causing is_plugin_active() to never match. Adds Multisite_Network_Installer_Test with 16 tests (49 assertions) covering get_steps(), get_config(), check_network_tables_exist(), and all branches of _install_network_activate() including idempotency and existing-plugin preservation. Fixes #837
superdav42
force-pushed
the
feature/auto-20260414-093848
branch
from
67c8750 to
f9ffe08
Compare
Merge SummaryIssue: #837 — The multisite setup wizard does not network activate the plugin Root cause: A secondary bug: the early-return guard used Fix: Replaced Changes:
Verification: All 16 new tests pass; PHPStan reports no errors. aidevops.sh v3.8.25 plugin for OpenCode v1.4.3 with claude-sonnet-4-6 spent 12m and 1,346 tokens on this as a headless worker. Overall, 1m since this issue was created. |
🔨 Build Complete - Ready for Testing!📦 Download Build Artifact (Recommended)Download the zip build, upload to WordPress and test:
🌐 Test in WordPress Playground (Very Experimental)Click the link below to instantly test this PR in your browser - no installation needed! Login credentials: |
🔨 Build Complete - Ready for Testing!📦 Download Build Artifact (Recommended)Download the zip build, upload to WordPress and test:
🌐 Test in WordPress Playground (Very Experimental)Click the link below to instantly test this PR in your browser - no installation needed! Login credentials: |
|
Performance Test Results Performance test results for f8c57a4 are in 🛎️! Note: the numbers in parentheses show the difference to the previous (baseline) test run. Differences below 2% or 0.5 in absolute values are not shown. URL:
|
PR #852 fixed _install_network_activate() to write directly to sitemeta, but two other code paths still allowed the wizard to report success without actually network-activating the plugin: 1. ajax_network_activate() on the requirements page still called activate_plugin() which silently falls back to single-site activation when OPcache serves a stale wp-config.php. Now delegates to Multisite_Network_Installer::_install_network_activate() for the same direct sitemeta write. 2. Multisite_Setup_Admin_Page::setup_install() was missing an explicit exit after wp_send_json_error(), which could allow the response to be corrupted if headers were already partially sent. 3. Base_Installer::handle() never checked whether COMMIT succeeded. A silently-failed COMMIT would roll back the sitemeta write on connection close, but handle() still returned success. Now checks the COMMIT return value and returns WP_Error on failure. Refs #837
PR #852 fixed _install_network_activate() to write directly to sitemeta, but two other code paths still allowed the wizard to report success without actually network-activating the plugin: 1. ajax_network_activate() on the requirements page still called activate_plugin() which silently falls back to single-site activation when OPcache serves a stale wp-config.php. Now delegates to Multisite_Network_Installer::_install_network_activate() for the same direct sitemeta write. 2. Multisite_Setup_Admin_Page::setup_install() was missing an explicit exit after wp_send_json_error(), which could allow the response to be corrupted if headers were already partially sent. 3. Base_Installer::handle() never checked whether COMMIT succeeded. A silently-failed COMMIT would roll back the sitemeta write on connection close, but handle() still returned success. Now checks the COMMIT return value and returns WP_Error on failure. Refs #837
1 participant
Summary
Fixes a race condition in the Multisite Setup Wizard where the final Network Activate Plugin step would sometimes silently fall back to single-site activation instead of network-wide activation.
Root cause
_install_network_activate()inMultisite_Network_Installercalledactivate_plugin(WP_ULTIMO_PLUGIN_FILE, '', true)to perform network activation. WordPress'sactivate_plugin()checksis_multisite()internally and uses theactive_sitewide_pluginssitemeta key only when multisite is active. Ifis_multisite()returnsfalse, it falls back silently to single-site activation.The MULTISITE constant is written to
wp-config.phpin the immediately-preceding step (_install_update_wp_config). Each wizard step runs in a separate AJAX request, but if OPcache or another PHP bytecode cache serves a stalewp-config.phpin the next request,is_multisite()returnsfalsein thenetwork_activatestep — producing the "appears to but doesn't, sometimes" behaviour from the issue.A secondary bug: the early-return guard used
is_plugin_active(WP_ULTIMO_PLUGIN_FILE)with the full absolute path instead of the plugin basename (WP_ULTIMO_PLUGIN_BASENAME), so the guard never fired.Fix
Replace
activate_plugin()with a direct write to thewp_sitemetatable, as the existing code comment already described as the intent. This bypasses theis_multisite()dependency entirely and guarantees reliable network activation regardless of bytecode caching.Files changed
inc/installers/class-multisite-network-installer.php— rewrites_install_network_activate()to write directly to{prefix}sitemetavia$wpdb->get_row/$wpdb->update/$wpdb->insert, usingWP_ULTIMO_PLUGIN_BASENAMEthroughouttests/WP_Ultimo/Installers/Multisite_Network_Installer_Test.php— 16 tests coveringget_steps(),get_config(),check_network_tables_exist(), and all branches of_install_network_activate()including idempotency and existing-plugin preservationVerification
Resolves #837